Fix Linq webhook onboarding and public ingress guidance - #12

Summary

• replace the misleading localhost webhook prompt with an explicit local Gateway path and public ingress choice
• support existing HTTPS ingress, path-scoped Tailscale Funnel guidance, Cloudflare Tunnel guidance, and explicit outbound-only setup
• require a public HTTPS target on the selected path before subscription creation and finish with a concrete readiness summary
• use OpenClaw's shared secret setup for masked plaintext input or env/file/exec SecretRefs
• guard every provider subscription create/delete through the host's persistent-effect hook when available
• keep webhook config account-scoped, preserve existing state when provider cleanup is declined or fails, and invalidate stale signing secrets after subscription replacement
• update the quickstart and production ingress examples, tighten all schema surfaces, and exclude local/test artifacts from package archives

Stack

Depends on #10. This branch is two commits on top of RomneyDa:linq-sdk-runtime-alignment:

RomneyDa/openclaw-linq-plugin@linq-sdk-runtime-alignment...linq-webhook-onboarding

Review the comparison above until #10 merges; the upstream PR diff will then collapse to this phase automatically.

Configuration contract

• webhookPath is the dedicated local OpenClaw Gateway route.
• webhookUrl is present only for a stable public HTTPS target using that exact path.
• outbound-only setup omits webhookUrl and webhookSecret.
• apiToken accepts plaintext or an OpenClaw SecretRef; live setup uses a resolved value without replacing the stored reference.
• existing working HTTPS configurations continue to load; the old nonfunctional HTTP/localhost shape and Gateway root path are intentionally rejected.
• tunnel commands are shown but never installed or executed by the wizard.

Validation

• OpenClaw 2026.6.1: typecheck and 13 test files / 55 tests pass
• OpenClaw 2026.7.1: typecheck and 13 test files / 55 tests pass
• source-linked plugin loads and registers the Linq channel on both supported hosts; plugins doctor reports no issues
• runtime and both manifest schema surfaces agree on recursive accounts, HTTPS webhook URLs, and dedicated paths
• unit proof covers masked token entry, resolved SecretRef setup, and guard ordering/failure propagation for provider creates and deletes
• npm pack --dry-run: 29 entries; no tests, local worktrees, roadmap files, env files, or credentials
• git diff --check passes

Follow-up boundary

Structured status and guided signed smoke diagnostics remain Phase 2 from #11. Direct package-archive installation on OpenClaw 7.1 also exposes a pre-existing source-only packaging gap: this repository does not yet publish compiled JavaScript. This PR verifies the supported source-linked loader path and keeps a build-output migration separate from onboarding behavior.

Closes the Phase 1 scope in #11.

Live provider proof

• ran the actual Phase 1 onboarding workflow against the Linq sandbox through a temporary exact-path public proxy
• real subscription creation succeeded, returned the create-only signing secret, and produced Inbound readiness: READY
• a temporary OpenClaw 2026.7.1 Gateway loaded the source-linked plugin and registered the selected account-scoped webhook path
• public ingress returned 404 for an unrelated path, 405 for webhook GET, and 401 for an unsigned webhook POST
• deleted the temporary Linq subscription and verified it was absent, then stopped the Gateway, tunnel, and path proxy, verified both local ports were closed, and removed temporary config/secrets
• signed inbound/reply behavior was not duplicated here because the unchanged messaging path is already proven by Align Linq messaging with the OpenClaw channel runtime #10